\chapter{User Interface}

In this part we focus on the study behind the User Interface of TBSimulator and its implementation. This point was developed after the backend deployment because it requires different analysis, strictly related to the contet we need to show. Each part in the navigation has to appear independent to the other, but all share the common relation to the navigation flow. The main phases at this point was to find the correct path in our model that offers a simple and good experience to the final user.


\section{General Aspects of View Developing}

Since we are not front-end designer we approach the task form an engineering point of view. We identify the main problem to solve and, applying the divide et impera mantra, we split it in many subtask that can be easily resolved with no technical skills in terms of esthetic fancy.


Our analysis process went trought this phases:
	
\begin{itemize}
\item View definition
\item State of the arts
\item Example selection
\item Reduction to a personalized model that tries to take pros the examples we have found;
\end{itemize}

As said we faced the problem with an engineeristic approach so that we study the work of other programmers. There are different patters in this context that can be followed to present a reasonable way to navigate through the application. In particular what is recurring the the best practice of gui developing is: understand that the user is both fascinated and scared by tinnovation, since  we have to proived a middle road  between make him feeling annoyed by a non-well design application and feeling lost facing a complete innovative GUI.

First of all we need to know how an activity screen can drive the user interaction::
\begin{itemize}
\item Top left corner features an app icon or a home icon. Tapping should take the user back, in in its navigation. Android phones have a built in back button since that we replicate this behaviour
\item Middle of the action bar will feature title of the screen to prevent user feeling lost without knowing where it is in the navigation flow.
\item Top right of the screen In this part of the screen there should only be actions that are related to the screen content, usually specific page settings, but in our case only the test require the user to interact with the bar, and this because we need to restrict a complex activity with a lot of content in a small view.
\item Bottom Right Corner and Bottom Left Corner are usually left empty of developed according to the next concept:
\item Bottom Middle Content: we decide to fill this part, that can be really accessibile by user first finger , with a topdown slider that presents and hides content according to user needs.
\end{itemize}

Moreover we understand that many aspects of the standard programming has influenced the way in which the application is thinked by programmers: an example that we analyse deeple in the next section is the importance of the pair List and Adapter to migrate programmatic content to the a consultable one.

In the end we crawled a bit about how the user navigates an application and how the interactions flow is  related to the content he found in the app. We have a system that need an agile user that enjoy the repetition of common task. 
 In the next section we see the main patterns that we think emphasize  main aspects of our project and valorise our application and the final choice in the development

\section{Common Patterns in UI Design}



\subsection{The Navigation Drawer}
In the first version of our application we decide to follow the standard pattern in the Android World. As can be seen surfing in the difference Store, the most common navigation flow is the paring of a Navigation Drawer and a Fragmented View that present content to the user. This kind of GUI is easy to be understand from the point of view of the programmer, since it doesn’t mediate the content representation. The options are simply listed to the user, and the order is the only attribute that really matters.

This kind of GUI is practical but doesn't satisfy many requrements in term of usability.


\subsection{The Dashboard Pattern}

We want to offer a single point of acces for our application, that make the user able to use it since the very first time it launch the application. Indeed is common knowledge that how an application presents itself to the user is the most important aspect in GUI development. 

Out application has more than one main functions so we looked for a way to present different options; dashboard shows off the most important ones provide easy shortcuts to them. This kind of GUI enhance the importance of items in the upper part and on the right, considering the right hand usage the most common with smartphone. The main drawback is the that the equality of a lot of choice can disorient the user, a good solution take care of common actions and make the recognisable.

\subsection{The List Screen}

As we anticipate the list is a very recurrent theme in android UIs especially for displaying content. The simplicity of this layout consist into exploiting elements order to guide user to satisfy his needs. However the each list item should be relative small to allow good overview of list content and put a lot information into a small area can make very difficult the interactions.

\subsection{The Grid Screen}

We build all the GUI in a modularity way, so we evaluate the possibily extends this kind of desing also to the layout structure: what in the Android world is called GridView. In the context of the main Activity we discarted this solution because is suffer from the tipical constrains of a fine grained construct, however we exploited this kind of view in other context, as the badge rapresentation and in part of profile view that requeire a more dynamick construction.

\section{The Project}

\subsection{A  "DashList" View}

Considering both the analysis we presented we start look for a kind of view that exploits all the pros. Our researches go through a lot of different layouts, but here we report only the two that influence most our decisions. In particular we found a very successful application that went across a similar view developing and that effects our choice: Evernote.

\subsubsection{Transeint content with a Sliding Panel}

After the main content presentation we start a looking for view elements that make possibile for the user to access all the content in the application without hard e difficult movements of fingers.
The experience of a navigation drawer for access simple list guide us to look for something similar that doesn’t require to change the way the user hold the phone. A bottom-up sliding panel is the perfect solution for accessing a dynamic transient list of notification and in the second hand we find perfecto also for the navigation during the test performance.

\subsection{The Test}

Considering both the analysis we presented we start look for a kind of view that exploits all the pros. Our researches go through a lot of different layouts, but here we report only the two that influence most our decisions. In particular we found a very successful application that went across a similar view developing and that effects our choice: Evernote.

\subsubsection{Subject Navigation with a Sliding Panel}

After the main content presentation we start a looking for view elements that make possibile for the user to access all the content in the application without hard e difficult movements of fingers.
The experience of a navigation drawer for access simple list guide us to look for something similar that doesn’t require to change the way the user hold the phone. A bottom-up sliding panel is the perfect solution for accessing a dynamic transient list of notification and in the second hand we find perfecto also for the navigation during the test performance.

\subsection{Statistics and Charts}